System and method for facilitating trading of financial instruments

ABSTRACT

A system and method for facilitating trading of financial instruments. According to one embodiment, an application receives an indication of interest to trade a financial instrument by a first party, provides the indication of interest to other parties without disclosing a side of trade, receives an offer to trade the financial instrument by a second party based on the provided indication of interest, a side of trade being associated with the offer by the second party but not disclosed to the first party, and receives either a rejection or an acceptance of the second party&#39;s offer by the first party.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a division of U.S. patent application Ser. No.11/191,046, filed Jul. 28, 2005. This application claims the benefitunder 35 U.S.C. §119(e) of U.S. Provisional Application No. 60/639,374,filed Dec. 23, 2004. This application is a continuation-in-part of U.S.patent application Ser. No. 10/840,378, filed May 7, 2004. Thisapplication is also a continuation-in-part of U.S. patent applicationSer. No. 10/730,360, filed Dec. 9, 2003, which claims the benefit under35 U.S.C. §119(e) of U.S. Provisional Application No. 60/431,913, filedDec. 9, 2002. U.S. patent application Ser. No. 10/840,378 and U.S.patent application Ser. No. 10/730,360 are hereby incorporated byreference, as if repeated herein in their entirety, including theirdrawings.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor patent disclosure as it appears in the Patent and Trademark Officepatent file or records, but otherwise reserves all copyright rightswhatsoever.

BACKGROUND OF THE INVENTION

As is well known, when buyers and sellers attempt to trade a largequantity of stock that is disproportional to the stock's average tradingvolume, buyers and sellers must carefully consider their options.Following is an analysis of the main trading systems that are availablefor institutional traders in today's markets.

Posit is an Alternative Trading System (ATS) which seeks to manageinformation to facilitate large block trades. In this method, usersenter orders into the trading system they want to trade including thesymbol of a stock and a maximum or minimum price they are willing toaccept for their buy or sell order. This system accumulates orders fromseveral market participants over a previously specified time period andcreates a master list of buy and sell orders. At a given random exacttime (at different times of the day) the system matches and executes allpossible contras in the system at the midpoint price of the NationalBest Bid and Offer (NBBO).

Pipeline Trading is another ATS that seeks to manage information tofacilitate large block trades. Users of this system create and submitfirm limit orders including the price, side of trade (i.e., buy or sell)and number of shares to a central order book, The trading systemdesignates a minimum order size for each stock that the trading systemwill permit to be entered. Generally, high volume large cap stocks areassigned a minimum of 100,000 shares and all the other tradable stocksare assigned 25,000 shares. Orders are placed and displayed based ontheir designated assigned minimum trading increment of 25,000 or 100,000shares, depending on the symbol.

In the central order book, other subscribers of the system are able tohit these displayed firm limit orders by entering firm buy or sellcontras. However, the central order book does not show the buy or sell“side of trade” of any of its limit orders or their prices to itssubscribers. Also, once an order reaches the central order book, it mustmeet an activation condition before it is offered to other users of thesystem.

This activation condition consists of a computer formula that calculatesa “block trading range” that the central order book considers to be areasonable price. This price range is based on average prices of priortrades for fixed amounts of prior traded volume. In order for limitorders to be activated and displayed in the central order book, theprice of the limit order must fall within this block trading range. Ifthe price of an order falls within this price range, the order is deemedfair and reasonably priced, and advertised to the users in the system bycoloring the symbol as active in the central order book. When asubscriber hits an active order in the central order book, he will haveto satisfy two conditions in order to execute a trade: first, his ordermust be contra to the order he is hitting, and second, his entered pricemust equal or cross the price of the sitting limit order he is hitting.If his order is not contra, then he is notified by the central orderbook.

To illustrate by example, assume a first party enters into the system'sorder book an order to buy 100,000 shares of IBM at or below a price of$89.56. (The $89.56 price and the side of the trade are hidden in theorder book.) A second party enters an order to sell 100,000 shares at$89.54. The system crosses the trade at $89.55—the midpoint pricebetween the two prices that are entered by the buyer and seller.

Thus, when a subscriber of the system wishes to grab a sitting limitorder in the central order book, he must enter a price based on hisguess of the price of the sitting limit order.

Pipeline only accepts very large minimum lot sizes of 25,000 or 100,000shares. The system falls to provide for trading orders of all lot sizes.

In most cases the system creates its own synthetic bid-ask spreadthereby creating its own midpoint price as well. It accomplishes this bycalculating a range by aggregating fills in the public market into25,000-share lots, calculating the highs and lows of the last five ofthese lots, and then calculating averages of the two extremes. Theresult is a synthetic bid-ask spread.

Liquidnet, another ATS, attempts to manage information to facilitatelarge block trades. The system continually combines all of its user'sblotters (daily scheduled trades) and creates a master blotter of allthe users of the system. This master blotter contains the user code,symbol, side of trade, and share size of all of the desired trades butexcludes the price. The system continually attempts to match prospectivebuyers and sellers. Once a match is discovered, the user is notified andgiven the opportunity to act upon that match by initiating an anonymousnegotiation through the exchange of text messages with the counter partyin a private that room. If they come to an agreement a trade iscompleted. Buyers and sellers must share with one another their tradinginterest in the private chat room in hopes of consummating a trade.Buyers and sellers are comfortable disclosing trading interest to oneanother because the trading system strictly limits its users to selectgroup of traders that it feels will not take advantage of this insideinformation.

The system has an approximate 4% fill rate from the trading interestthat is expressed in the master blotters it receives, even thoughprobably only 20% of the master blotter is matched. Few matches resultin trades.

Nasdaq Stock Market manages large numbers of limit orders at any giventime during trading hours. All market participants such as investors,traders and market makers place limit orders in this trading system.Because of ever improving technology, a new method of trading isbecoming more common. This new method is called “sweeping the book” or“walking the book down.” A “sweep” occurs when a limit order is pricedbetter than the NBBO. Once entered, this type of order results inexecutions at multiple price points at and away from the NBBO.

To illustrate by example, assume an investor places an order to buy 5000shares of XYZ stock at $9.00 and this quote becomes the NBB. Let ussuppose further that there are buy orders for 1000 shares at $9.95 and5000 shares at $8.75 and 500 shares of XYZ stock at $8.70. A minutelater a second order comes in to sell 20,000 of XYZ stock at $8.75. Thissell order first grabs the investor's order of 5000 shares and thengrabs the other limit orders of 1000 at $9.95 and 5000 shares at $8.75.Any limit order that is priced equal or greater than $8.75 will begrabbed until the 20,000 order is filled. In this example, this resultsin filling 11,000 shares of the sell order. The remainder of 9000 sharesbecomes the NBO and the new NBB becomes $8.70. In less than a second,the investor has a fill at $9.00 but has already taken a financial lossin the position of 3.33% or $1,500 on a $45,000 purchase.

This investor who placed the limit order to buy 5000 shares of XYZ stockwas “picked off” by the sweep. Although he got a fill at his price, heregretted placing the order because of his immediate financial loss.Sweeping increases price volatility and diminishes the ability oftraders to buy and sell at stable prices. This results in fewer limitorders being placed in this type of trading system. Nasdaq Stock Marketfails to protect limit orders from “being picked” off during a sweep.This increases the costs of limit order placement and thus reducesliquidity in this market.

The New York Stock Exchange (“NYSE”) is another trading system thatattempts to manage information to facilitate large block trades. Thissystem relies on having a person (specialist) at a specific real estatelocation called a “post.” These posts are located on the floor of theNYSE. The specialist stands around his post and takes orders from floorbrokers. Floor brokers represent their institutional customers with buyand sell orders. Through verbal and hand signals, floor brokerscommunicate with the specialists. In many instances there are severalfloor brokers standing, yelling and chattering around the specialistpost. The purpose of this yelling and chattering is to communicate buyand sell orders of their institutional customers to the specialist andother floor brokers. Floor brokers share their institutional customers'buy and sell orders with other floor brokers in attempt to fill theircustomers' orders. In many instances a floor broker may discover thatother floor brokers are attempting to find contra parties for largeorders on the same side of trade (buy or sell). When this occurs itreveals to many of the floor brokers hanging around the booth that onesided buy or sell trading interest exits and this trading interest wantsto immediately come into the market. Once this trading interest isrevealed, new smaller (buy or sell) orders are generated on the sameside and are immediately placed in the market ahead of the larger ordersthat are sitting on the sidelines still looking for a contra. Thesesmaller orders move the price of the stock against the large orderssitting on the sideline. This information leakage increases the tradingcosts for institutional investors that trade listed stocks. The openoutcry trading system of the NYSE fails to operate without leakingvaluable inside trading interest to unintended third parties, resultingin increased costs for traders who use this trading system.

When a limit order is entered into the Nasdaq Stock Market and New YorkStock Exchange the market is impacted in all cases by an increase in thebuy or sell trading interest. Nasdaq Stock Market allows traders to showonly a portion of their limit order to the market. This practice ofhiding shares reduces the market impact of limit order placement.However, it introduces other problems for traders. Hiding shares reducesthe chances of attracting a contra party that can take out the entiresize of the order with reserve shares in one trade. If a trader sends anorder that is larger than what is required to take out the limit orderwith reserve shares, he impacts the market by becoming the quote of theNBBO. This results in needlessly displaying left over shares to themarket. Nasdaq Stock Market and New York Stock Exchange fail to preventmarket impact when limit orders are placed into their trading systems.

In the Nasdaq Stock Market and NYSE limit orders sit in order books andwait for a contra party to trade with. Generally, the limit order has agood chance of execution only if the price reaches the best bid or askprice. Occasionally, limit orders are executed away from the best bid orask price due to a market sweep. Limit orders that are priced at theNBBO have much greater chance of execution than limit orders that arepriced inferior to the NBBO. This situation basically creates twodifferent types of limit orders, one type that is priced at the NBBO andanother type of limit order that is priced away from the NBBO. Thecurrent trading systems of Nasdaq and NYSE do not differentiate betweenthese two types of limit orders. Nasdaq and NYSE trading systems fail toprovide any incentive to traders to place limit orders away from theNBBO and thus reduce the amount and size of limit orders that could beplaced into their order books.

Posit, Pipeline, Liquidnet, Nasdaq Stock Market and NYSE trading systemshave flaws in how buyers and sellers communicate with one another, howthese systems determine the final execution price of matched orders andhow these systems protect information generated by order placement.

Accordingly, there is a need in the art for a system and methods thatimprove communications, improve price discovery, prevent informationleakage and protect limit orders from sweeps, which will result inbetter executions.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram that depicts blind-side trade offering basedon an indication of interest in accordance with an embodiment of thepresent invention.

FIG. 2 is a block diagram that depicts blind-side trade acceptancecontingent upon a market event condition in accordance with anembodiment of the present invention.

FIG. 3 is a block diagram that depicts automatic matching and offeringof indications of interest in accordance with an embodiment of thepresent invention.

FIG. 4 is a block diagram that depicts automatic matching, offering andacceptance of indications of interest in accordance with an embodimentof the present invention.

FIG. 5 is a block diagram that depicts automatic matching of offers totrade with indications of interest in accordance with an embodiment ofthe present invention.

FIG. 6 is a block diagram that depicts automatic matching and acceptanceof offers and indications of interest in accordance with an embodimentof the present invention.

FIG. 7 is a block diagram that depicts condition based trade orderaccess in accordance with an embodiment of the present invention.

FIG. 8 is a block diagram that depicts market event condition basedtrade execution in accordance with an embodiment of the presentinvention.

FIG. 9 is a block diagram that depicts a data structure associated withan indication of interest to trade a financial instrument in accordancewith an embodiment of the present invention.

FIG. 10 is a block diagram that depicts a peer-to-peer trading systemarchitecture in accordance with an embodiment of the present invention.

FIG. 11 is a block diagram that depicts communications data flow for apeer-to-peer trading system in accordance with an embodiment of thepresent invention.

FIG. 12 is a flow chart that depicts a display protocol for indicationsof interest in accordance with an embodiment of the present invention,

FIG. 13 is a flow chart that depicts associating a rating to anindication of interest in accordance with an embodiment of the presentinvention.

FIG. 14 is a block diagram that depicts a trading system user interfacein accordance with an embodiment of the present invention.

FIG. 15 is a screenshot that depicts a main screen of a peer-to-peertrading system in accordance with an embodiment of the presentinvention.

FIG. 16 is a screenshot that depicts a IOI modification window of apeer-to-peer trading system in accordance with an embodiment of thepresent invention.

FIG. 17 is a screenshot that depicts a make offer window of apeer-to-peer trading system in accordance with an embodiment of thepresent invention.

FIG. 18 is a screenshot that depicts a main screen of a peer-to-peertrading system showing active offers in accordance with an embodiment ofthe present invention.

FIG. 19 is a screenshot that depicts an offer modification window of apeer-to-peer trading system in accordance with an embodiment of thepresent invention.

FIG. 20 is a screenshot that depicts an offer response window of apeer-to-peer trading system in accordance with an embodiment of thepresent invention.

FIG. 21 is a screenshot that depicts a main screen and daily blotter ofa peer-to-peer trading system in accordance with an embodiment of thepresent invention.

FIG. 22 is a screenshot that depicts a blotter manager window of apeer-to-peer trading system in accordance with an embodiment of thepresent invention.

FIG. 23 is a flow chart that depicts a buyer and seller negotiating atrade in accordance with an embodiment of the present invention.

FIG. 24 is a screenshot that depicts a main screen of a peer-to-peertrading system in accordance with an embodiment of the presentinvention.

FIG. 25 is a screenshot that depicts another main screen of apeer-to-peer trading system in accordance with an embodiment of thepresent invention.

FIG. 26 is a screenshot that depicts a main screen and make offer windowof a peer-to-peer trading system in accordance with an embodiment of thepresent invention.

FIG. 27 is a screenshot that depicts a main screen of a peer-to-peertrading system indicating that a market event condition associated withan offer has been met in accordance with an embodiment of the presentinvention.

FIG. 28 is a screenshot that depicts a main screen of a peer-to-peertrading system indicating that a market event condition associated withan offer has not been met in accordance with an embodiment of thepresent invention.

FIG. 29 is a screenshot that depicts a main screen and offer responsewindow of a peer-to-peer trading system in accordance with an embodimentof the present invention.

FIG. 30 is a screenshot that depicts a main screen of a peer-to-peertrading system indicating that a market event condition associated withan accepted offer has not been met in accordance with an embodiment ofthe present invention.

FIG. 31 is a screenshot that depicts another main screen of apeer-to-peer trading system indicating that a market event conditionassociated with an accepted offer has not been met in accordance with anembodiment of the present invention.

FIG. 32 is a block diagram that depicts opposite side dummy ordergeneration in accordance with an embodiment of the present invention.

FIG. 33 is a block diagram that depicts an automated multiple partysimultaneous trade execution in accordance with an embodiment of thepresent invention.

FIG. 34 is a block diagram that depicts condition based trade orderactivation using price deviations off prices from trailing time periodsin accordance with an embodiment of the present invention.

FIG. 35 is a block diagram that depicts a computing device in accordancewith an embodiment of the present invention.

DETAILED DESCRIPTION

The present invention addresses the deficiencies of current tradingsystems by increasing the quality of communications between buyers andsellers and eliminating information leakage that occurs before a tradecan be completed.

These benefits may be realized through the use of an indication ofinterest (“IOI”) in accordance with embodiments of the presentinvention. An IOI is defined, for purposes of this application, as anexpression of a trader's interest in trading a financial instrument. AnIOI does not commit nor obligate the trader to enter into a tradeagreement based on the trade information associated with the IOI unlessspecified by the trader. An IOI may comprise one or more pieces of tradeinformation such as, for example, financial instrument identifier,amount of shares, minimum share requirement or side of trade. Afinancial instrument may include, for example, stocks, ETFs, funds,bonds, contracts, options, futures, commodities or currencies.

FIGS. 1-2 depict blind-side trade offering and acceptance between afirst user at trading client 1000 connected with a second user attrading client 1010 via communication network 1005 in accordance with anembodiment of the present invention. In FIG. 1, trading client 1000receives an IOI entered by the first user (step 100) specifying aninterest in trading a financial instrument; the first user may or maynot specify a side of trade in connection with the IOI. Trading client1000 subsequently provides the first user's IOI without the side oftrade (if one was specified) to others (step 110) by, for example,sending the IOI to a central trading server for display in an orderbook. Trading client 1010 displays the order book listings to the seconduser, and receives from the second user terms of an offer, including aside of trade, to be made on the IOI (step 120). Trading client 1010then submits the offer without the side of trade (step 130) to tradingclient 1000 for acceptance or rejection by the first user (step 140).

In FIG. 2, trading client 1000 receives from the first user anacceptance of the second user's blind-side offer along with a side oftrade to be associated with the acceptance (step 200). Trading client1000 subsequently provides notification of the first users acceptancewithout the associated side of trade (step 210) to trading client 1010(step 220). Only upon satisfaction of a market event conditionassociated with the accepted offer (step 230) does trading client 1000disclose to trading client 1010 the side of trade associated with theacceptance (step 240). At this point, trading client 1010 determineswhether the first user's side associated with the acceptance is contrato the second user's side associated with the offer (step 250). If thetwo sides are contra (i.e., one is a buy and the other a sell, orvice-versa), then trading client 1010 completes the trade (step 260) by,for example, submitting the completed trade details to the tradingserver for execution.

If both the offer and acceptance are on the same side (two buys or twosells), trading client 1010 may notify trading client 1000 that theoffer and acceptance were on the same side. One advantage of sharingfailed trade data between both parties of the failed trade is that bothparties may receive legal inside information, similar to the situationwhen a floor broker learns about another floor broker's trading interestand is able to profit from this information. Additionally, informationon the failed trade need not be disclosed to a trading server.

FIGS. 3-6 depict automatic matching of IOIs by a trading server inaccordance with embodiments of the present invention. In particular,FIG. 3 describes an embodiment in which an IOI may be associated with an“auto-offer” instruction. In FIG. 3, trading client 1000 receives an IOIentered by a first user (step 300) specifying an interest in trading afinancial instrument, along with an indication authorizing tradingserver 1020 to automatically offer to trade the financial instrument onthe first user's behalf based on the IOI's trade information. Tradingclient 1000 provides the IOI and authorization indication to tradingserver 1020 (step 310), which then searches for matching IOIs (step320). A matching IOI is one that specifies trade information (e.g.,financial instrument identifier, amount of shams, side of trade, etc.)that could potentially fill an offer based on the trade informationspecified in the first user's IOI. For example, a matching IOI mayspecify a financial instrument symbol identical to that of the firstuser's IOI, a share amount at or above that of the first user's IOI,and/or a side of trade contra to that of the first user's IOI. Uponidentifying a matching IOI, trading server 1020 generates an offer inconnection with the matching IOI (step 330), which may then be submittedto a trading client machine of a second user associated with thematching MI for acceptance or rejection by the second user.

FIG. 4 describes an embodiment in which an IOI may be associated with an“auto-offer” and/or an “auto-accept” instruction. Steps 400, 410 and 420of FIG. 4 are identical to steps 300, 310 and 320 of FIG. 3. However, instep 430, upon identifying a matching IOI, trading server 1020determines if the matching IOI is associated with an indicationauthorizing trading server 1020 to automatically accept an offer totrade. If so, trading server 1020 completes a trade (step 440) betweenthe first user and a second user associated with the matching IOI, basedon the trade information associated with the first users IOI. If not,trading server 1020 generates an offer in connection with the matchingIOI (step 450), which may then be submitted to a trading client machineof the second user for acceptance or rejection by the second user.

FIG. 5 describes an embodiment in which a trading server matches tradeoffers with IOIs. In FIG. 5, trading client 1000 receives an offer totrade a financial instrument entered by a first user (step 500). Tradingclient 1000 provides the offer to trade to trading server 1020 (step510), which then searches for matching IOIs (step 520). A matching IOIis one that specifies trade information (e.g., financial instrumentidentifier, amount of shares, side of trade, etc.) that couldpotentially fill the offer provided by trading client 1000. For example,a matching IOI may specify a financial instrument symbol identical tothat of the provided offer, a share amount at or above that of theprovided offer, and/or a side of trade contra to that of the providedoffer. Upon identifying a matching IOI, trading server 1020 forwards theoffer to a trading client machine of a second user associated with thematching IOI (step 530) for acceptance or rejection by the second user.

FIG. 6 describes an embodiment in which a trading server matches tradeoffers with IOIs that may be associated with an “auto-accept”instruction. Steps 600, 610 and 620 of FIG. 6 are identical to steps500, 510 and 520 of FIG. 5. However, in step 630, upon identifying amatching IOI, trading server 1020 determines if the matching IOI isassociated with an Indication authorizing trading server 1020 toautomatically accept an offer to trade. If so, trading server 1020completes a trade (step 640) between the first user and a second userassociated with the matching IOI, based on the trade informationassociated with the first user's offer to trade. If not, trading server1020 forwards the offer to a trading client machine of the second user(step 650) for acceptance or rejection by the second user.

FIGS. 7-8 depict the enforcement of order access and trade executionconditions, respectively, in accordance with embodiments of the presentinvention. These conditions provide the advantage, for example, ofprotecting limit orders from being “picked off” from “sweeps”.

In FIG. 7, trading server 1020 provides to trading client 1000 an orderbook listing that includes an order to trade a financial instrumentspecifying a condition (e.g., a time period delay, occurrence of amarket event, etc.) to be met in order for the order to be accessed fortrading (step 700). Trading client 1000 displays the order andassociated access condition to a user and subsequently receives theuser's acceptance of the access condition (step 710). Trading client1000 notifies trading server 1020 of the user's acceptance (step 720),and trading server 1020 waits until the access condition has been met(step 730) before allowing the user to access the order (step 740).

In FIG. 8, trading server 1020 provides to trading client 1000 an orderbook listing that includes an order to trade a financial instrumentspecifying a market event condition (e.g., a market value reaching aspecified price associated with the financial instrument, etc.) to bemet in order for the order to be completed upon acceptance (step 800).Trading client 1000 displays the order and associated market eventcondition to a user and subsequently receives the user's acceptance ofthe market event condition along with the order (step 810). Tradingclient 1000 notifies trading server 1020 of the user's acceptance (step820), and trading server 1020 waits until the market event condition hasbeen met (step 830) before completing the order (step 840).

FIGS. 9-10 depict a computer implementation of an IOI and trading systemin accordance with an embodiment of the present invention. An IOI maytake any form, such as the data structure of FIG. 9 in which IOI 900comprises data elements: symbol 910 representing an identifier for afinancial instrument (e.g., shares 920 representing a total amount ofshares of the financial instrument a user is interested in trading, minshares 930 representing a minimum amount of shares that the userrequires to be filled in any potential trade, side 940 representing aside of trade, access condition 950 representing a condition to be metin order for the IOI to be accessed for trading, trade executioncondition 960 representing a market event condition to be met in orderfor an order based on the IOI's trade information to be completed uponacceptance, auto-offer 970 representing the user's authorization to atrading server to automatically offer to trade the financial instrumenton the user's behalf based on the IOI's trade information, auto-accept980 representing the user's authorization to a trading server toautomatically accept an offer to trade the financial instrument on theuser's behalf based on the IOI's trade information, and user IOI 990representing a network identifier for the user's trading client machine.Of course, IOI 900 may include additional data elements or any subset ofdata elements to adequately express the user's trading interest.

FIG. 10 illustrates a peer-to-peer arrangement in which trading server1020 controls the trade quote and execution process, while facilitatingtrade negotiation communication between trading client 1000 and tradingclient 1010. Trading server 1020 includes quote process 1022, IOIdatabase 1024, execution process 1026 and completed trades database1028, and receives live market data from data vendor 1030. Quote process1022 receives live market data from data vendor 1030, which may beutilized by trading clients 1000 and 1010 for preparing IOIs, offers andacceptances, and by trading server 1020 for verifying market events asdescribed in FIGS. 7-8. IOI database 1024 stores the IOIs generated bytrading clients 1000 and 1010. Execution process 1026 completes acceptedoffers and stores completed trades in completed trades database 1028.

FIG. 11 depicts an embodiment of the present invention in which tradingserver 1020 facilitates the communication of trade negotiation detailsbetween trading clients 1000 and 1010, but is not intended to accessinto the trade negotiation details.

When a first user at trading client 1000 desires to enter into a tradenegotiation with a second user at trading client 1010 (e.g., to make anoffer based on an IOI), trading client 1000 sends two data packets totrading server 1020: a first data packet enclosing trade negotiationdetails 1100 (such as details of an offer on an IOI), and a second datapacket enclosing identification code 1110 (e.g., user IOI 990 obtainedfrom IOI 900) representing the intended recipient of the communication(i.e., trading client 1010). The first data packet may be encrypted toprevent access by trading server 1020 via any secure communicationsmechanism such as, for example, the industry accepted public keyinfrastructure (PKI) using an RSA encryption algorithm.

Upon receipt of trade negotiation details 1100 and identification code1110, trading server 1020 generates reference code 1120 to representcommunications for this particular trade negotiation between tradingclients 1000 and 1010, and associates reference code 1120 withidentification information for trading clients 1000 and 1010 in aninternal data structure. Trading server 1020 then sends anacknowledgement message to trading client 1000 with reference code 1120,so that trading client 1000 can use reference code 1120 to identifyfurther communications for this particular trade negotiation. Tradingserver 1020 also routes trade negotiation details 1100 to trading client1010 (identified by trading server 1020 via identification code 1110)with reference code 1120, so that trading client 1010 can use referencecode 1120 to identify further communications for this particular tradenegotiation,

When trading client 1010 desires to respond to trading client 1000(e.g., to accept an offer based on an trading client 1010 sends two datapackets to trading server 1020: a first data packet enclosing furthertrade negotiation details 1102 (such as details of an acceptance of anoffer on an IOI), and second data packet enclosing reference code 1120to identify the trade negotiation communication. Upon receipt of tradenegotiation details 1102 and reference code 1120, trading server 1020cross references reference code 1120 in its internal data structures fortrade negotiation communications to identify trading client 1000 as theintended recipient of the communication, and subsequently routesnegotiation details 1102 to trading client 1000. The first data packetfrom trading client 1010 may also be encrypted as discussed above toprevent access by trading server 1020 into the details of the tradenegotiation communication.

FIGS. 12-13 depict methods for facilitating the display of IOIs inaccordance with embodiments of the present invention. In FIG. 12, atrading server may organize an IOI order book such that in order for auser to view the IoIs of other users, the user must enter an IoI thatspecifies enough shares to satisfy any minimum fill requirements ofother IoIs in the trading system. For example, upon receiving a user'sIOI specifying a share amount (step 1200), trading server 1020determines whether there are other IOIs listed in the trading system(step 1210), and if so, retrieves the minimum share requirement of thenext listed IOI (step 1220). If the listed IOI's minimum sharerequirement amount is less than or equal to the user's IOI share amount(step 1230), then trading server 1020 displays the listed IOI to theuser (step 1240). This process is then repeated until all listed IOIsare analyzed. Thus, this IOI display mechanism essentially provides adark order book, in which users of large IoIs can see small IoIs, butusers of small IoIs cannot see large IoIs.

In FIG. 13, a trading server may display a rating next to an IOI listingto indicate an expected quality of the IOI based on the responsivenessof the IOI originator on previous IOIs of the originator. This isadvantageous because users making offers on IOIs are more likely to dealwith IOIs with higher ratings. For example, upon receiving a user's IOI(step 1300), trading server 1020 determines a performance rating for theuser (step 1310), such as a probability that the user will accept orcounter an offer made on the IOI, and displays the rating along with theIOI (step 1320). In accordance with an embodiment of the presentinvention, the performance rating in step 1310 may be calculated usingthe following scoring rules:

1. The IOIs of a user to be analyzed are the most recent IOIs posted bythe user and which have received offers, up to a maximum of 20 IOIs. Theuser's rating defaults to zero.

2. An IOI is marked as negative if the user responded to the IOI with adecline or did not respond at all. No points are added to the user'srating for a negative IOI.

3. An IOI is marked as positive if the user responded to the IOI with anoffer acceptance or with a counter offer. Five points are assigned tothe user's rating for a positive IOI.

4. Once an IOI is marked as positive, it remains positive until it isfilled or deleted.

5. The rating is calculated as the percentage of positive IOIs out ofthe total IOI's considered.

6. The ratings are in the range from 0 to 100, with 100 being thehighest.

For example, on a new IOI, assume a user is unable to respond to thefirst offer made on the user's IOI and the offer expires. This eventwould be considered a negative IOI, and might lower the user's rating.Then, if the user declines another offer on the same IOI because theshare quantity is not satisfactory, the IOI would remain negative butthe user's rating would not be lowered further. However, if the useraccepts or counters the next offer made on the IOI, the IOI would bereclassified from negative to positive, and the user's rating wouldrise. Thereafter, the IOI would remain positive, with neither declinesnor expirations negatively affecting the user's rating in connectionwith that IOI.

FIGS. 14-22 depict graphical user interfaces provided by trading clients1000 and 1010 in accordance with a peer-to-peer embodiment of thepresent invention. FIG. 14 depicts an arrangement for a main displayscreen comprising a data entry section (1430), and 3 data displaysections: IOI display 1400, local offers display 1410 and outside offersdisplay 1420.

FIG. 15 illustrates a screenshot representation of this main displayscreen. The data entry 1430 section of FIG. 15 is labeled “EnterIndication of Interest”, and provides multiple fields to allow users tocreate new IOIs. A user may create one IOI per symbol, and an IOI may berequired before the user can view other users' IOIs for that symbol (inaccordance with the display mechanism of FIG. 12). The fields of dataentry 1430 section of FIG. 15 may have the following characteristics andrestrictions:

1. Symbol—Required field; must be a valid stock symbol; specialcharacters and numbers are not allowed.

2. Shares—Required field; must be a valid whole number, not more than10,000,000. This is the number of shares that a user is requesting, andthis number is displayed to other qualified users.

3. Min. Shares—Optional field; if not specified, defaults to 0. Thisfield is used for two purposes: 1) to ensure that any offers that aresent to the user are sufficiently sized and 2) to ensure that the user'sIOI is not visible to smaller parties, thereby hiding the user's tradinginterest.

4. Side of Trade (Buy/Sell)—Optional field; kept private on the user'strading client machine. This field indicates whether the user intends tobuy or sell. This field is used to default the Buy/Sell choice on theMake Offer screen (FIG. 17), the Accept Offer screen (FIG. 20), and alsoin the Auto-Accept and Auto-Offer features.

5. Time Limit Optional field; kept private on the user's trading clientmachine.

This field accepts a number and units (either hours, minutes, orseconds), defaulting to 3 minutes. It indicates what the default TimeLimit should be for offers to be made. This field is used on the normalMake Offer screen, but also by the Auto-Offer feature.

6. Price Type (Fixed Midpoint/Peg to Midpoint)—Optional field; keptprivate on the user's trading client machine. This field indicates whattype of price the system should default to for offers. Specifically, theuser would choose Fixed Midpoint or Peg to Midpoint as the Price Typeoptions. This field would be used to default the values on the normalMake Offer screen, but also by the Automatic Offer feature.

7. Price Limit—Optional field; kept private on the user's trading clientmachine. This field indicates what min/max price would be used as alimit for a Peg to Midpoint type of order. This field applies if thePrice Type chosen is Peg to Midpoint and would be used on the normalMake Offer screen, but also by the Auto-Offer feature. Also, this fieldwould be used by the Auto-Accept feature.

8. Auto-Offer—Optional field; kept private on the user's trading clientmachine. This field indicates whether the user wants the system toautomatically make offers to other parties. This option is onlyavailable if the Side of Trade is pre-entered.

9. Auto-Accept—Optional field; kept private on the user's trading clientmachine. This field indicates whether the user wants the system toautomatically accept offers that arrive, assuming that the price of theoffer is on the current midpoint (other embodiments could includedifferent market values). This option is only available if the Side ofTrade is pre-entered.

10. Clear Options—This button dears all values from the OptionalFeatures fields so that no optional features are associated with theIOI.

11. Enter—This button validates the data, and submits theSymbol/Shares/Min. Shares to trading server 1020 so that the IOI can bebroadcast to all eligible users. The private IOI fields are notsubmitted to trading server 1020. If the IOI is configured asAuto-Offer, then trading server 1020 begins the Auto-Offer process uponactuation of this button.

The IOI display 1400 section of FIG. 15 is labeled “Indications ofInterest”, and displays Symbol, Shares and Rating for all IOIs availablefor the user to see. The user's own IOIs are displayed in peach color,while other users' IOIs are displayed in teal. The list may only showother IOIs which have Minimum Shares less than or equal to the user'sshares. The fields of IOI display 1400 section of FIG. 15 may have thefollowing characteristics and restrictions:

1. Symbol—The symbol as entered when the IOI was created.

2. Shares—The shares as entered when the IOI was created.

3. Rating—The rating for each IOI (in accordance with the ratingmethodology of FIG. 13). Every user is assessed a rating based on howthe user responds to offers made to the user on previous IOIs. Thus, theratings for both the local IOIs and the outside IOIs may change as theIOI originators receive and respond to offers.

This “Indications of Interest” section of the user interface may exhibitthe following functionality:

1. Once a user places an offer based on an outside IOI, the text of theoutside IOI may “wiggle” from side to side, until the user's offer (asdisplayed in the local offers display 1410 section of FIG. 15 labeled“Your Offers”) becomes inactive (e.g., due to expiration, cancellation,execution, etc.).

2. Once the user's offer becomes inactive, the user may want to knowwhich IOI the user has already offered, and the result of that offer.The color of the outside IOI may change to dark teal, and the finalstatus of the offer may be indicated next to the shares of the IOI.Specifically, if the user's offer was declined, the outside IOI may bemarked with a “D”, while an expiration may be marked with an “X”. If theuser reaches the point where the other party's trade intention wasdisclosed to the user (either through a successful execution or througha same-side failure), this intention is displayed as “B” or “S” next tothe shares of the IOI.

3. The list of IOIs may be scrolled using the scroll bar provided, orvia a mouse wheel.

4. The View All IOIs button may be clicked to provide the user with aview of more IOIs on a single page.

The local offers display 1410 section of FIG. 15 is labeled “YourOffers”, and allows the user to monitor those offers which the user hasmade to other users. Offers are placed into this list when the userchooses an outside IOI and makes an offer, and also when the user makesa counter offer to someone's outside offer (displayed in the outsideoffers display 1420 section of FIG. 15 labeled “Outside Offers”). Thefields of local offers display 1410 section of FIG. 15 may have thefollowing characteristics and restrictions:

1. Buy/Sell—This field indicates whether the user's offer is to buy orsell, but this intention is not communicated to the other user untilnecessary. Once the other party has blindly accepted the user's offer ofsymbol/shares/price, and once the midpoint price has crossed, only thenis the user's buy/sell intention revealed. Only then does the user teamif the user has a successful trade, or if both parties were on the sameside of the trade.

2. Symbol—The symbol of the offer.

3. Shares—The number of shares of the offer.

4. Price—The price of the offer. If the offer was created with Peg toMidpoint as the Price Type, then this field contains the word “Midpoint”instead of a fixed price and may continually flash red. If the offer wascreated with Fixed Midpoint, then the price on the offer is the midpointprice of the stock at the time the offer was initiated. In order for theoffer to be executable, the midpoint has to equal or cross this price.(Other embodiments could include market values other than the midpoint.)

5. Time Left—This field is a declining time to expiration. If no actionis taken before the time reaches 0:00, then the offer expires. Once theoffer becomes inactive, this field holds the final status of the offer.

6. Midpoint—This field is the floating (i.e., live) midpoint price forthe stock. Once the midpoint equals the price, then the offer iseligible for execution, and it may flash in a red color. If the Price is“Midpoint” then the offer will continually flash in a red color.

This “Your Offers” section of the user interface may exhibit thefollowing functionality:

1. When the user's offer has been accepted by the other party, and theuser is simply waiting for the midpoint to cross, the offer may flashgreen.

2. When the user is awaiting a response from the other user, but themidpoint price for the stock matches the midpoint price on the offer (orif the Price Type was Peg to Midpoint), then the user's offer may flashin a red color.

3. When the user's offer becomes inactive, it may be colored gray.Depending on the user's Show Inactive Orders setting, these inactiveoffers may disappear from the screen automatically.

4. The Your Offers section shares a scroll bar with Outside Offerssection.

The outside offers display 1420 section of FIG. 15 is labeled “OutsideOffers”, and allows the user to monitor those offers which the user hasreceived from others. Offers are placed into this list when someonemakes the user an offer based on the user's IOI, and also when someonemakes a counter offer to one of the user's offers. The fields of outsideoffers display 1420 section of FIG. 15 may have the followingcharacteristics and restrictions:

1. Symbol—The symbol of the offer.

2. Shares—The number of shares of the offer.

3. Price—The price of the offer, generated as the midpoint price of thestock at the time the offer was initiated. In order for the offer to beexecutable, the midpoint has to be equal to or cross this price.

4. Received—This field displays the time that the user received theoffer, based on the user's local computer clock. The user's localcomputer time is visible in the upper right hand corner of this screen.

5. Time Left—This field is a declining time to expiration. If no actionis taken before the time reaches 0:00, then the offer expires. Once theoffer becomes inactive, this field holds the final status of the offer.

6. Midpoint—This field is the floating midpoint price for the stock.Once the midpoint equals the price, then the offer is eligible forexecution and may flash red.

This “Outside Offers” section of the user interface may exhibit thefollowing functionality:

1. When the user has accepted an outside offer and is simply waiting forthe midpoint to cross, the offer may flash green.

2. When the user has not yet responded to an outside offer, but themidpoint price for the stock matches the midpoint price on the offer,then the outside offer may flash red.

3. When the outside offer becomes inactive, it may be colored gray.Depending on the user's Show Inactive Orders setting, these inactiveoffers may disappear from the screen automatically.

4. The Outside Offers section shares a scroll bar with the Your Offerssection.

The following are additional features illustrated on the user interfaceof FIG. 15:

1. Show Inactive Offers—This checkbox controls whether offers remainvisible after they become inactive, e.g., after they become cancelled,expired, executed, etc. By default, this checkbox is set to false,meaning that inactive offers disappear from the screen, leaving onlythose active offers that are currently pending. If the user sets thischeckbox to true, the user sees the inactive offers in the listincluding their details and final status.

2. View All IOIs—This button launches a separate screen geared towardviewing a large quantity of IOIs. The main screen may display only 25IOIs at a time, but the All IOIs screen may display 125 at once. Theuser may still need to use the main screen for monitoring Your Offersand Outside Offers.

FIG. 16 depicts a “Modify Your IOI” window, which is displayed when theuser dicks on the user's own IOI, or when the user right dicks on theuser's own IOI and chooses “Modify” from the menu. This window allowsthe user to change an IOI after it has been entered. The functionalityof the different field values are described above in connection with the“Enter Indication of Interest” section, and only augmented as follows:

1. Symbol Original symbol for the IOI; not editable.

2. Shares—Defaulted with the current number of shares for the IOI, butcan be changed to any whole number between 1 and 10 million. If the userincreases or decreases the user's number of shares, it may affect theIOIs that are visible to the user, based on the minimum shares of thoseIOIs.

3. Min. Shares—Defaulted with the current minimum shares for the IOI,but can be changed to any whole number between 1 and 10 million.

4. Buy/Sell—Defaulted with the current Side of Trade for the IOI, butcan be changed for the offer. Changing from Buy to Sell or vice versamight have consequences when used in combination with Auto-Offer orAuto-Accept.

5. Time Limit—Defaulted with the Time Limit values for the IOI, but canbe changed for the offer.

6. Fixed Midpoint/Peg to Midpoint—Defaulted with the Price Limit settingfor the IOI, but can be changed for the offer.

7. Price Limit—Defaulted with the Price Limit setting for the IOI, butcan be changed for the offer.

8. Auto-Offer—Defaulted with the Auto-Offer setting for the IOI, but canbe changed for the offer.

9. Auto-Accept—Defaulted with the Auto-Accept setting for the IOI, butcan be changed for the offer.

10. Clear Options—This button clears all values from the OptionalFeatures fields so that no optional features are associated with theIOI.

11. Modify—This button validates the data and, as with entering a newIOI, only the Symbol/Shares/Min. Shares are submitted to trading server1020 to be broadcast out to all eligible users.

12. Cancel IOI—This button submits a cancellation request to tradingserver 1020, so that the IOI can be deleted from all users' displays.This cancellation request may also be initiated by right-clicking on theIOI, and choosing “Cancel IOI” from the menu. Once the user cancels theuser's own IOI, all of the outside IOIs will also be removed from theuser's display.

13. Close—This button dismisses this screen, with no action taken.

FIG. 17 depicts a “Make Offer” window, which is displayed when the userclicks on any outside IOI, or when the user right-clicks on an outsideIOI and chooses “Make Offer” from the menu. An offer in this embodimentis the combination of buy/sell, shares, symbol, price and time limit.Once the offer is entered, it is displayed in the Your Offers section ofthe user's main trading screen, while it is displayed as a new offer inthe Outside Offers section of the other party's main trading screen. Asdescribed in the “Indications of Interest” section, the outside IOI may“wiggle” while the offer is active. The fields of the “Make Offer”window of FIG. 17 may have the following characteristics andrestrictions:

1. Buy/Sell—Required field. These buttons allow the user to indicatewhether the user is offering to buy or sell the selected stock (otherfinancial instruments may be included in different embodiments). Theuser's buy/sell intention is not transmitted to the other party untilnecessary. In fact, the user's intention is kept secret on the user'scomputer until a trade is ready for execution, and only then is ittransmitted to trading server 1020. This field value is defaulted fromthe user's IOI settings.

2. Shares—Required field. This represents the number of shares that theuser is offering to transact. This value is defaulted from the lesser ofthe two values when comparing the number of the user's IOI shares andthe outside IOI shares. The number of shares can be changed, but may notbe less than the Minimum Shares defined in the outside IOI.

3. Symbol—Defaulted from the outside IOI. Not editable.

4. Fixed Price/Peg Price to Midpoint—The price shown on the screen isthe midpoint at the time that the screen is displayed and it is noteditable. The user may choose this fixed midpoint price, or may chooseto float the midpoint by selecting Peg Price to Midpoint. Once thisoption is chosen, the Price Limit field becomes editable. Choosing thePeg Price to Midpoint causes the order to be constantly executable,unless the Price Limit is exceeded. This Price Type field value isdefaulted from the user's IOI settings but can be changed.

5. Price Limit—Optional field. This field is only editable if the PriceType chosen is Peg Price to Midpoint This field value is kept privatefrom the other party and once an offer is made, it is used toautomatically cancel the offer if the price limit is exceeded. If noPrice Limit is entered, then the offer price will float without pricelimit, but only within the time limit. This field value is alsodefaulted from the user's IOI settings but can be changed.

6. Time Limit—When the user places an offer, it is good for a designatedtime period of the user's choosing. The default time limit is 3 minutes,but the default may be altered to fit the user's needs simply byentering an amount of time, and then choosing “seconds”, “minutes” or“hours”.

7. Yes—This button validates the user's data entry and sends the offerto the other party. At that time, it is displayed under Your Offersalong with any other offers the user has made.

8. No—This button cancels the offer entry with no action taken.

FIG. 18 depicts the main trading screen showing active offers, with theoffer in the Your Offers column colored in red.

FIG. 19 depicts a “Modify Offer” window, which is displayed when theuser clicks on one of the user's offers that is active, or when the userright-clicks on the user's offer and selects “Modify Offer” from themenu. By default, nothing is modifiable on this screen, but by clickingthe Change Shares, Update Price, Change Price Limit or Reset Time Limitbuttons, the user can change the Shares, Price, Price Limit or TimeLimit on the user's order. One or all of these offer fields can bemodified before the user submits the new offer. The user can also cancelthe user's offer from this screen. The fields of the “Modify Offer”window of FIG. 19 may have the following characteristics andrestrictions:

1. Change Shares—When the user clicks the Change button, the number ofshares becomes an editable field.

2. Update Price—When the user dicks the Update button, the price of theoffer updates to the current midpoint price.

3. Change Price Limit—When the user clicks the Change button, the pricelimit of the offer becomes an editable field. This button is onlyenabled if the Price Type is Peg Price to Midpoint.

4. Reset Time Limit—When the user clicks the Reset button, the timefields become visible, allowing the user to change the unit of time(either seconds, minutes or hours) and well as the number of units.

5. Modify—Clicking the Modify button validates the data, and submits theuser's changes to trading server 1020. Trading server 1020 theninactivates the original offer, and submits a new offer to the otherparty with the modified field values.

6. Cancel Offer—Clicking the Cancel Offer button initiates acancellation process with trading server 1020, which notifies the otherparty that the user's offer has been cancelled. This action can also beaccomplished by right-clicking the user's offer, and selecting “CancelOffer” from the menu.

7. Close—The Close button is used to dismiss this window, with no actiontaken.

8. Remove—When right-clicking the user's offer, the user sees a Removeoption in the menu. This menu item is used to remove an inactive offerfrom the display once the user is finished viewing it. If the userattempts to remove the user's offer while it is still active, the systemprompts the user to first cancel the offer before removing it from thedisplay.

FIG. 20 depicts a “Respond to Offer” window, which is displayed when theuser dicks on an Outside Offer that is active, or when the userright-clicks on an Outside Offer and chooses “Respond to Offer”. Thisscreen allows the user to make three different responses to the offer,each with different results. The fields of the “Respond to Offer” windowof FIG. 20 may have the following characteristics and restrictions:

1. Buy/Sell—Required field. These buttons are only used if the user isConfirming (accepting) the offer. They allow the user to indicatewhether the user is agreeing to buy or sell the selected stock. Theuser's buy/sell intention is not transmitted to the other party untilthe midpoint crosses, and the trade can be executed. Only upon midpointcross is the user's intention communicated to the other party andtrading server 1020, and only then does the user learn if the user has agood trade or a same-side failure. If the user configures the Buy/Sellintention when the creating the user's IOI, then it is pre-populatedwhen this screen is loaded, but is an editable value.

2. Confirm—Clicking the Confirm button after choosing Buy or Sellindicates that the user has agreed with the symbol, shares and priceoffered, and that the user is committing to execute the trade, providedthat the other party is on the opposite side (i.e. buying when you areselling, or vice versa). Of course, the trade will not actually executeuntil the midpoint crosses the price, but both parties are committedpending that event, and provided that neither party cancels before thatevent. In addition, confirming the user's acceptance notifies the otherparty that the user has accepted his offer, and that both are awaitingmidpoint cross before each party's side is revealed. To indicate thatthe user is awaiting midpoint cross, the offer flashes in a green colorfor each party. This is a positive rating event.

3. Counter—The Counter button is used when the offer either the shares,price or time limit are not satisfactory. When the user chooses to makea counter offer, then the Make Offer Window is displayed, allowing theuser to create a new offer with the user's own shares, price and timelimit. When the user agrees to make the counteroffer, the Outside Offeris marked as Countered, and it becomes inactive. The new offer is placedinto Your Offers, just as though the user had made the offer originally.As for the other party, his original offer is marked as inactive andCountered in Your Offers, while the new offer will be shown as active inOutside Offers. This is a positive rating event.

4. Decline Offer—Clicking the Decline Offer button sends a notificationto the other party indicating the user's refusal. On both computers, theoffer is marked as Declined and inactive. This is a negative ratingevent.

5. Close—The Close button is used to dismiss this window, with no actiontaken.

6. Remove—When right-clicking the outside offer, the user sees a Removeoption in the menu. This menu item is used to remove an inactive offerfrom the display once the user is finished viewing it. If the userattempts to remove an outside offer while it is still active, the systemprompts the user to first decline the offer before removing it from thedisplay.

Trading server 1020 may allow users to convert a scheduled daily list oftrades that need to be done (blotter) into IoIs and upload thisinformation into trading server 1020. Trading server 1020 then mayattempt to match internally potential matches and send messages to itsusers attempting to initiate the entering of offers and direct theseoffers to contra parties, or simply internally match and execute thematches according to instructions from the users, such as in accordancewith the embodiments described in FIGS. 3-6, for example.

FIG. 21 depicts a screenshot of the main trading screen illustrating alist of “daily trades to do” (Daily Blotter), which may initially beloaded via a Blotter Upload Feature and displayed on the far left of thescreen. The user's Daily Blotter may be displayed on the left side ofthe main trading screen throughout the application's use. The DailyBlotter enables the monitoring of trading tasks, enables the navigationbetween the different trading screens, and enables the modification ofall IOIs and orders with one user action.

A Blotter Upload feature allows a user to bulk-load Blotter data intothe trading client application instead of entering the data directlyinto the Blotter screens. The Blotter data may be stored in a standardMicrosoft Excel file format that the trading client application couldread. Once the data is loaded via Blotter Upload, it can be modifiedthrough a blotter modification screen. The following fields may besupported for upload to the Blotter:

1. Symbol—The symbol of the IOI; required field.

2. Shares—The number of shares to be transacted; required field.

The following are optional fields which could remain on the tradingclient application and not be shared with trading server 1020:

1. Side of Trade—This field would indicate whether the user intends tobuy or sell.

This field would be used to default the Buy/Sell choice on the MakeOffer screen, the Accept Offer screen, and also in the Auto-Accept andAuto-Offer features.

2. Automatic Accept—This field would indicate whether the user wants thesystem to automatically accept offers that arrived, assuming that theprice of the offer is on the current midpoint. This option would only beapplicable if the Side of Trade was pre-entered.

3. Automatic Offer—This field would indicate whether the user wants thesystem to automatically make offers to other parties. This option wouldonly be applicable if the Side of Trade is pre-entered.

4. Price Type—This field would indicate what type of price the systemshould default to for offers. Specifically, the user would chooseCurrent Mid or Peg to Midpoint as the Price Type options. This fieldwould be used on the normal Make Offer screen, but also by the AutomaticOffer feature.

5. Price Limit—This field would indicate what min/max price would beused as a limit for a Peg to Midpoint type of order. This field onlyapplies if the Price Type chosen is Peg to Midpoint. This field would beused on the normal Make Offer screen, but also by the Auto-Offerfeature.

6. Time Limit—This field would indicate what the default Time Limitshould be for offers. This would be entered as a number of seconds. Thisfield would be used on the normal Make Offer screen, but also by theAuto-Offer feature.

The blotter may include the following monitoring capabilities:

1. The blotter initially is displayed in a collapsed format, but theuser can double-click each top-line to drill down to more detailedinformation.

2. The collapsed top-line view is displayed in the following format:“<Symbol>−<Number of Shares>” (e.g. “MSFT−10000”).

3. If the Side of Trade is entered, then the format is:“<Symbol>−<Buy/Sell> <Number of Shares>” (e.g. “MSFT−Buy 10000”).

4. Using coloration and drilling down on each symbol for more detailedinformation, the user can monitor his entire blotter in an efficientmanner.

For Filled Shares:

5. If the symbol's entire quantity of shares has been filled throughtrading in trading system 1020, the coloring of the top-line and allchild lines below may be red, indicating that no further action isrequired for that symbol.

6. Upon double-clicking on the top-line, the user may see only one linerepresenting the summary of the order executions for that symbol. It maybe displayed in the following format: “Filled <Number of Shares> @$<Average Price>” (e.g. “Filled 20000 @ $24.95”).

7. Upon double-clicking on that summary line, the user may be able tosee the specific executions that made up the summary line. Specifically,executions may be displayed in the following format: “<Number of Shares>@ $<Price> (<System>)” (e.g. “12000 @ $24.92 (Deep)”). (“Deep” mayinclude any integrated trading system.) Totaling the filled sharesacross the detail lines should equal the filled quantity from thesummary line. Similarly, averaging the prices across the detail linesshould equal the average price from the summary line. The <System> valuein the detail line indicates which system processed the execution.

For Unfilled Shares:

8. If the symbol has open orders in trading system 1020, but has notexecuted any shares, the coloring of the top-line and all child linesbelow may be green, indicating that no shares have been filled and thefull quantity is still available.

9. Upon double-clicking on the top-line, the user may see only one linerepresenting his open IOI position in the following format: “Open<Number of Shares> (IOI)” (e.g. “Open 20000 (IOI)”). If there is no openIOI position, the user may see “Enter IOI” instead.

10. In addition to the IOI line, the user may see at least one lineOrder Book orders. If there is an Order Book order, it will be in thefollowing format: “Open <Number of Shares> (Deep)” (e.g. “Open 8000(Deep)”). If there is no order in the Order Book, the user will “EnterOrder” instead.

For Partially Riled Shares:

11. If the symbol still has open shares, but has also executed someshares trading system 1020, the coloring of the top-line and all childlines below may be yellow, Indicating that the task has been started butnot completed.

12. Upon double-clicking on the top-line, the user's display may be acombination of the Filled and Unfilled functionality described above.

For No Orders:

13. If the symbol has no open orders and no filled orders, the coloringof the top-line and all child lines below may be white, indicating thatno orders at all have been created.

14. Upon double-licking on the top-line, the user may see two linesbelow it, Enter IOI and Enter Order.

In addition to the monitoring functionality as described, the Blotterscreen allows the user to navigate through the application, as follows:

1. Double-clicking on a top-line brings up the Blotter modificationscreen, allowing the user to change the settings for that symbol.

2. Double-clicking on a “Filled” line from trading system 1020 takes theuser to the

Daily Open Positions screen, which is automatically loaded with allpositions opened for the day.

3. Double-licking on an “Enter IOI” line takes the user to the maintrading screen and populates all fields based on values found in theblotter data, or in the System Defaults. Unless changes to the defaultsare required for this symbol, the user should be able to simply clickthe Enter button to post the IOI.

4. Double-clicking on an “Open” IOI line takes the user to the maintrading screen, and automatically scrolls the list of IOIs so that hisIOI is at the top.

5. Double-clicking on an “Enter Order” line takes the user to an orderbook of an integrated trading system, where the user can enter thesymbol and click Go to display all current orders for that symbol. Inaddition, the Symbol, Shares, and Buy/Sell will be pre-populated tospeed up the Order Entry process.

6. Double-clicking on an “Open” line of an integrated trading systemtakes the user to the order book of the integrated trading system andautomatically enters the symbol, where the user may click Go to displayall Deep orders for that symbol, along with the current bid/ask/lastetc.

In addition to monitoring and navigation, a Blotter Manager allows theuser to make changes to all IOIs at once. By clicking on a BlotterManager button, the user sees the Master Blotter Controller screen ofFIG. 22. The Blotter Manager provides the ability for a user to settrading conditions for all of the stocks in the user's daily blotter.The fields of the “Blotter Manager” window of FIG. 22 may have thefollowing characteristics and restrictions:

1. Enter Indications of Interest—When the blotter is first loaded, it isassumed that no orders will be present in the system. The Master BlotterController makes it very simple for the user to create IOIs for each ofhis symbols with a single click. To do this, the system uses the blotterdata about each symbol to fill in the IOI fields and create the IOI. Anyfields not present in the blotter data will be defaulted from the SystemDefaults.

2. Modify All IOIs—Once the ION are created, this screen can be used toapply one or more changes to the entire list of IOIs.

a) Auto-Accept—This checkbox turns on or turn off the Auto-Accept optionfor each IOI. If any IOI does not have a Side of Trade (Buy/Sell)configured, the Auto-Accept option will not be set for that IOI, and anerror will be displayed.

b) Auto-Offer—This checkbox turns on or turn off the Auto-Offer optionfor each IOI. If any IOI does not have a Side of Trade (Buy/Sell)configured, the Auto-Accept option will not be set for that IOI, and anerror is displayed.

c) Fixed Midpoint—This button turns on Fixed Midpoint pricing defaultused when submitting offers, either through manual offers or throughAuto-Offer.

d) Peg to Midpoint—This button turns on Peg to Midpoint pricing defaultused when submitting offers, either through manual offers or throughAuto-Offer.

e) Time Limit—This field changes the default time limit used whensubmitting offer, either through manual offers or through Auto-Offer.

3. Cancel All IOIs—Choosing this option allows the user to cancel all ofhis IOIs. Since the underlying IOI data is still retained in the blotterinformation, the user can re-create them easily. They can all be enteredat once through the “Enter Indications of Interest” option on the MasterBlotter Controller, or they can be entered individually through the Peerto Peer screen.

In connection with the Auto-Accept feature in this embodiment, when anIOI is created, either through the main trading screen or via BlotterUpload, and the Side of Trade is specified, then Auto-Accept optionbecomes available. The Auto-Accept feature allows a user to configure anIndication of Interest to automatically accept when a live mid-pricedoutside offer is made. An outside offer would be deemed executable ifthe price on the offer matched the current midpoint for the symbol.Optionally, the user could add a Price Limit to the IOI that wouldimpose an additional condition: the system would not Auto-Accept to Buyabove the Price Limit, nor to Sell below the Price Limit.

In connection with the Auto-Offer Feature in this embodiment, when anIOI is created, either through the main trading screen or via BlotterUpload, and the Side of Trade is specified, then the Auto-Offer optionbecomes available. The Auto-Offer feature allows a user to configure anIndication of Interest to automatically make offers to Outside IOIsuntil the IOI quantity is completely filled. To support this task, theuser configures a few additional fields. The Price Type field allows theuser to choose whether the price should be fixed as the Current Midpointat the time, or whether the price should be Pegged to the Midpoint.Optionally, the user could add a Price Limit to the Auto-Offer processthat would impose an additional condition: the system would notAuto-Offer to Buy above the Price Limit, nor to Sell below the PriceLimit. If the price moves beyond the Price Limit, then the Auto-Offerfeature would stop sending offers, and cancel any outstanding Peggedoffers.

Offers typically are only good for certain time period, but if outsideIOIs are configured with the Auto-Accept option, it is probable that themany IOIs can be completely filled instantaneously. Thus, with theAuto-Offer feature, trading system 1020 first trades with parties thathave configured their IOI to Auto-Accept all offers. Trading system 1020attempts to submit the offer to a given outside IOI, but if that IOI isnot configured for Auto-Accept, then the offer would be immediatelyretracted, and trading system 1020 would proceed to the next IOI. If theoutside IOI is configured for Auto-Accept, then the offer may besubmitted to the other party, and an outcome determined immediately.Once the entire list of outside IOIs is examined for Auto-Accept,trading system 1020 would then examine the Time Limit propertyconfigured for the IOI. Trading system 1020 then makes offers to thenon-Auto-Accept outside IOIs with the specified Time Limit value suchthat each offer would expire within a certain amount of time. If no timelimit is specified, then the offers will be good for a period of 3minutes.

Once the IOI is created and Auto-Offer set to true, trading system 1020automatically sends out one offer at a time until the share quantity iscompletely filled. The first offer will be made to the outside IOI atthe top of the list, the one which has the largest number of sharesavailable. The offer will be made following the same rules of the manualoffer process (i.e. the minimum and maximum share restrictionsconfigured for the outside IOI will be observed).

Once an offer is extended, there are several possible outcomes:

-   -   If the trade fails due to expiration, decline or same-side, then        trading system 1020 makes an offer to the next IOI in the list.    -   If the trade succeeds and the IOI shares are completely filled,        then the Auto-Offer process terminates for this IOI.    -   If the trade succeeds but the IOI shares are not completely        filled, then trading system 1020 continues to make offers to the        other IOIs until all shares are filled or all avenues are        exhausted.    -   If the other party makes a counter offer, then the Auto-Accept        parameters are utilized to determine the next action. If the        Auto-Accept feature is not chosen for an IOI, then the user has        to manually intervene to accept or decline the Counter Offer.        Either way, the Auto-Offer process will wait until this        conversation is completed before proceeding to the next IOI in        the list.    -   If all outside IOIs are contacted but the IOI shares remain        unfilled, then trading system 1020 continues to monitor the        outside IOIs and makes immediate offers as new IOIs are        detected.

If an outside offer is received while there is a pending Auto-Offerextended to another party, trading system 1020 examines the shares ofboth offers compared to the IOI share quantity to determine theappropriate action. If accepting the outside offer would leaveinsufficient shares remaining in the IOI to fulfill the offer that wasautomatically extended, then the automatic offer is cancelled before theoutside offer is accepted to prevent the trading of too many shares.Once the IOI is adjusted based on the newly filled shares, but the IOIshares are not completely filled, then the Auto-Offer process continuesto make offers as described.

FIG. 23 provides an example of buyer 2300 (first party) and seller 2320(second party) negotiating a trade in accordance with an embodiment ofthe present invention. In step 2320, the first party enters an IoI byentering in the number of shares (75,000), the symbol (IBM) and theminimum fill requirement (50,000) in the client application running onhis computer. The first party does not enter the side of the trade(either buy or sell). The first party's client application thentransmits an encrypted 75,000 share, IBM IoI to the main trading system.In step 2330, the second party enters a 60,000 share IBM IoI with a30,000 share minimum fill requirement. Immediately, the second partyviews the other IoIs for IBM, which have a minimum fill requirement of60,000 shares or less in accordance with the IOI display method of FIG.12.

The second party's 60,000 share IBM IoI is equal or greater than the50,000 share minimum fill requirement of the first party's 75,000 shareIBM IoI. If the second party had entered anything less than a 50,000 IBMshare IoI, he would not be able to view the IoI of 75,000 IBM shares.Since the second party's IoI is equal or greater than 50,000 shares ofIBM, the first party's IOI is retrieved from the main trading system anddisplayed in second party's client application directly under his own60,000 share IBM IoI (step 2340). The first party also views the secondparty's IoI for 60,000 shares directly below his 75,000 share IBM IoIbecause the 75,000 share IBM IoI is greater than the 30,000 shareminimum fill requirement of the second party's 60,000 share IOI. FIG. 24depicts the main trading screen of the first party after submission ofthe IOIs, and FIG. 25 depicts the main trading screen of the secondparty after submission of the IOIs.

In step 2350, the second party clicks on the first party's IoI of“75,000 shares of IBM” and a pop-up appears requesting the side oftrade, shares and offer time, as depicted in FIG. 26. The price isalready filled in at $76.295, which is the current IBM midpoint price ofNBBO derived from an independent live market data feed at the moment thesecond party clicked on the IoI displayed in his client application.Once the Make Offer dialog popup appears, the second party has thechoice of Buy or Sell. Once the second party chooses Sell for the sideof trade, he has the option to modify the Shares field which initiallyfills at 60,000, which is the amount of the second party's IoI. Thesecond party also has the option to place a limited amount of time thathe wants to make his offer good for. He enters “3 minutes” for the timeperiod of the offer, and thus the trade details of selling 60,000 sharesof IBM at $76.295 good for 3 minutes is entered and transmitted to thefirst party's client application. The transmission of the trade detailsbetween the first and second party's client applications may be inaccordance with the peer-to-peer communication protocol of FIG. 11.

As depicted in FIG. 25, once the second party enters the offer, theoffer is displayed on second party's Your Offers column on his clientapplication as an offer and is colored red when the offer is firm andavailable, such as when the price equals the live midpoint price in thisembodiment. When the midpoint price moves away from the offer price, theorder becomes inactive. The order is reactivated when the midpoint pricereturns to the price of the offer.

In step 2360, the first party's client application receives the secondparty's offer (outside offer) from second party's client applicationalong with a notification of the offer, which may include a pop-upnotification appearing on the first party's display screen, an audiorecording stating “You have an offer”, a flashing light on top of thefirst party's computer beginning to flash, etc. The second party's offeris displayed on the first party's Outside Offers column on the clientapplication as depicted in FIG. 28. If the outside offer price wereequal to the live midpoint price, the offer would be colored red,indicating the offer is firm and available for execution; however, themidpoint price has moved to $76.285.

64 seconds after receiving the offer, the first party dicks on secondparty's outside offer and a dialog pop-up appears allowing the firstparty to accept, counter or cancel second party's offer. The pop-up alsoallows the first party the choice to click “Buy” or “Sell”. In thisexample 60,000 shares of IBM at $76.295 is automatically filled in thedialog box displayed in the first party's client application. He chooses“Buy” and then accepts the offer (step 2370), as depicted in FIG. 29. Hecannot modify the number of shares, symbol or price of the outsideoffer. If he is not satisfied with the outside offer, he can alwaysclick counter and an offer dialog box will appear with 60,000 shares ofIBM and new live midpoint price will automatically be filled in theoffer dialog box. A counter offer dialog popup box is identical to adialog pop-up box generated by clicking on an IoI; the only differenceis a counter offer dialog box automatically fills the live midpointprice and symbol of the outside offer, while clicking on an IoI thedialog box automatically fills the contents of the IoI. Countering anoutside offer simply reverses the process; the party that received anoffer basically cancels it and generates a new offer.

Once the first party has accepted the offer, the first party's clientapplication then checks to see if the midpoint price is equal to$76.295. If the price of the match were equal to the midpoint price of$76.295, the first party's client application would send the firstparty's order details including the side of trade (IBM, 60,000, $76.295and Buy) to the second party's application to determine if the side ofthe first party's acceptance is contra to the side of the second party'soffer. If so, an execution should be granted so the second party'sapplication would transmit the complete details of the transaction(Trade: Buy 60,000 shares of IBM at $76.295, Sell 60,000 shares of IBMat $76.295) to the main trading system for execution. The main tradingsystem would then verify the credit of the two parties to the trade and,if the party's market data feed was not muted through the main tradingsystem, verify whether the live midpoint price is the same as the priceof the accepted order. If the verifications are positive, the maintrading system would execute the trade and send confirmations out to thefirst and second party's client applications.

However, in this example when the first party accepts the second party'soffer, the current price of the symbol (IBM) is at $76.290, which is notequal to the mutually agreed upon midpoint price $76.295 of the accepted(matched) offer. As shown in FIG. 30, the offer is thus posted in theOutside Offers column of the first party's client application as green,which indicates that a match has occurred but is waiting for a priceevent (i.e., midpoint crossing in this embodiment) to occur. When ordersare matched, the timer of the original offer may be deactivated, and thematches may be cancelled individually by either party to the match.

Because the price event has not yet occurred, the first party's clientapplication transmits to the second party's client application orderdetails withholding the side of trade (Buy 60,000 shares IBM at$76.295). Once the trade details are received at the second party'sclient application (step 2380), the accepted offer is displayed in theYour Offers column also as green, awaiting the midpoint cross as shownin FIG. 31 (which shows a midpoint price of $76.285).

One minute later the midpoint touches $76.295, reactivating the orderfor execution. Upon reactivation, the first party's client applicationtransmits the side of trade to the second party's client application todetermine whether the acceptance and offer sides are contra. The secondparty's client application compares the sides and determines that theacceptance side (Buy) is contra to the offer side (Sell). Upondetermining the sides are contra, the second party's client applicationtransmits the trade (Buy 60,000 shares of IBM at $76.295, Sell 60,000shares of IBM at $76.295) to the main trading system for execution.

Reactivation would have also occurred in this example if the midpointdid not touch but crossed the agreed upon midpoint price (i.e.,$76.295). Crossing the midpoint price means that the price of themidpoint price is higher than the agreed upon midpoint price and thenbecomes lower than the agreed upon midpoint price, or vice versa, butdoes not stop at the agreed upon price.

If the second party's client application compared the two sides of thetrade and determined that both the first and second parties were on thesame side (i.e., two buys or two sells), then it would have notified thefirst party that the second party is same side and that the tradefailed. Both the first party's client application and the second party'sclient application may post the failed execution in a “same side failedtrades” section of their client applications and mark the correspondingIoIs with their side in each of their client applications. In thisevent, the main trading system does not know that a failed trade hadoccurred, and this information may be strictly the property of the twoparties of the failed trade.

The enforcement of order access conditions as embodied in FIG. 7 allowsliquidity providers (e.g., any trader who places a limit order into anorder book) to restrict other traders from accessing their quotes byincluding an access condition with their order. This trading methodallows the liquidity provider to set a minimum and maximum time periodin seconds that he wants a prospective liquidity taker delayed inaccessing his quote. This means when a liquidity taker clicks on asitting limit order with this functionality in trading server 1020, anorder confirmation pop-up may appear and state that his order entry maybe delayed up to the assigned maximum amount of time as prescribed bythe liquidity provider's limit order.

In one embodiment, after the order confirmation pop-up is agreed andentered by the liquidity taker, the liquidity taker's client applicationassigns a random time period between the minimum and maximum time periodof the sitting limit order. The liquidity taker's order is thentransmitted once the assigned random time period elapses providing thesitting limit order is still available. The liquidity taker does notknow the assigned random time period. He will only know that he mustwait the maximum time delay that is stated in the pop-up. If the orderhe is hitting becomes unavailable during this time delay period, theliquidity taking order need never be sent to the trading server 1020.However, if the order he is hitting is unavailable, the liquiditytaker's computer generates a new random number and repeats the processuntil either the liquidity taker's order or the liquidity provider'sorders are cancelled or expired.

In another embodiment, trading server 1020 receives the agreed uponorder and calculates the random time period. In this case each step ofthe process is communicated from both the liquidity provider andliquidity taker to trading server 1020 where trading server 1020determines if the access condition has been met. In yet anotherembodiment, the access condition may be any agreeable market event thatboth the buyer and seller can agree on. This can be a market eventderived from a computer program connected to live market data.

Illustrating by means of an example, assume a first party places a limitorder to buy 2000 shares of IBM at $89.00 and clicks on an option in hisclient application that requires that any contra trader be restricted toaccess his quote for 5 to 10 seconds. The first party's limit order isthen sent and placed in trading server 1020's order book. The secondparty clicks on first party's order and is given the option to accept orreject the first party's access restriction requirement of 5 to 10seconds. The second party accepts the first party's restrictionrequirement, and the second party's client application assigns a randomtime of 6.3 seconds as the time period between 5 and 10 seconds. A timerruns until 6.3 has elapsed, and once 6.3 seconds has elapsed, the secondparty's client application checks to see if the first party's order isstill available. If it is available, the second party's order is sent totrading server 1020 where it is executed with the first party's order.If the first party's order has been deactivated (e.g., because the pricechanged or if live market data triggered a deactivation condition of thefirst party's order), the second party's client application repeats theprocess until the second party cancels his order or the order of thefirst party is cancelled.

In another embodiment, the timing functionality may be conducted attrading server 1020 and not the client application of the second party.In yet another embodiment, the time-delay access restriction can bedisplayed next to the limit order in trading server 1020's order book.In a further embodiment, the time delay can be a fixed time.

FIG. 32 depicts an embodiment in which opposite side dummy orders aregenerated. In this embodiment, buy and sell trading interests areneutralized when a limit order is entered into the market (steps 3200and 3210) by generating a dummy limit order that is an exact replicawith an opposite side and priced inversed to the prevailing inside quoteof the actual order (steps 3220, 3230, 3240 and 3250). This dummy orderreduces market impact because the market participants cannot tell thedifference between the genuine order and the dummy order. Only when afirm order attempts to trade with the genuine or dummy order is the siderevealed and only to the party hitting the order.

Example: A buy limit order containing 10,000 shares of IBM is placed anddisplayed at the bid price. At the same time a dummy limit order to sell10,000 shares of IBM is placed and displayed at the ask price. If thegenuine order is pegged to the bid price, then the dummy sell order ispegged to the ask price, and vice versa. If the genuine limit order isreduced due to a partial fill, then the dummy order is also reduced. Ifthe genuine order is deactivated or cancelled, the dummy order islikewise deactivated or cancelled. If the genuine limit order is peggedand priced at a set price distance below the bid, then the dummy orderis priced at a set price distance above the ask, and vice versa. Thedummy order is an exact opposite artificial replica and shadow of theoriginal. Both the genuine and dummy orders can be marked by a symbolsuch as an asterisk in the central order book. This lets all users ofthe central order book know that there is only a 50% chance that eithermarked order is genuine. In another embodiment multiple limit orders areused provided that an equal level of opposite trading interest iscontained in dummy limit orders thus balancing buy and sell tradinginterest.

If a fixed priced limit order using this embodiment is placed into themarket, a dummy limit order is placed with the same number of shares andis priced opposite to the fixed priced limit order as it relates to themidpoint price of the best bid or offer price. Example: if a buy orderis entered priced 2 cents below the midpoint price, then a dummy sellorder is priced 2 cents above the midpoint price. If the bid and askprice move, the genuine and dummy orders stay the same at their enteredprices. Firm liquidity taking orders that are routed to pick off dummylimit orders wilt receive an electronic notice that the targeted limitedorder is a dummy. If a dummy order becomes priced better than amarketable price, one or both of the genuine and dummy orders can becancelled or deactivated.

In order to achieve a greater efficiency when using a dummy limit order,a trader may set a minimum fill requirement as described above for thegenuine and dummy limit orders. This prevents the pinging of a largelimit order with a small limit order simply for the purpose of revealingthe side of the large limit order.

In another embodiment, parties place IOIs into a central order book andindicate a willingness to receive offers priced inferior to the NBBO.Other trading participants of the central order book are able to clickon the desired IOI and make offers to the IOI originator. IOIs in thecentral order book do not reveal their side. When an IOI originatorreceives an outside offer, which is generally good for only a fewminutes, it appears that there are two offers. One of the offers isgenuine. The other offer is a dummy, priced at the opposite pricedistance and direction in relationship to the opposite side of the NBBO.For example, if an offer to buy is priced two cents under the bid price,then the dummy offer to sell is priced two cents above the ask price.The MI originator must attempt to execute a trade with either offer inorder to determine which order is genuine and which is a dummy. Thismethod allows traders to advertise willingness to trade at prices belowmarket in order to buy or sell a large block of shares. In anotherembodiment, the IOI originator pre-enters his side of IOI. Thissimplifies the process because the trading system will only displayoffers that are of opposite side. The party sending the offer is notnotified that his offer was not reviewed. In another embodiment, the IOIoriginator discloses the side of his IOI.

FIG. 33 depicts another embodiment that provides for an automatedmultiple party simultaneous trade. This transaction provides anincentive to market makers and liquidity providers to place large limitorders into a central order book in exchange for a good execution, onethat is better priced than NBBO prices. In exchange for placing largelimit orders into the central order book (steps 3300, 3310, 3320, 3330,3340 and 3350), the central order book allows liquidity providers firstdibs on sweeping better priced limit orders before the liquidity takercan grab the better priced limit orders (step 3360). If a prospectivetrader picks off a large limit order, the party who placed the largelimit order can sweep the better-priced smaller limit orders. This ismade possible because the party taking liquidity agrees to gives up hisimmediate access to smaller better priced orders which if traded willprobably result in upsetting the market and not completely filling hisorder, in exchange for a guaranteed fill of his larger order at a fixedprice even if the negotiated price is inferior to the market.

Example A: first trader places a large limit order, priced inferior tothe NBBO, into a central order book. A second party dicks on the firstparty's inferiorly priced order in the central order book and executeswith it. Simultaneously, the trading system identifies better pricedsmaller orders by third parties and executes with them on behalf of thefirst party, thus allowing the first party to make an instant profit onat least a portion of the shares he received from the second party.

All trade executions priced better than the first party's price may begiven to the first party. The first party offers the second party aguaranteed price in exchange for a guaranteed set number of shares. Inexchange for this offer, the second party grants the first party firstdibs on the better priced limit orders available in the market. Thecombined number of shares displayed at the better prices should be lessthan the first party's offer. If the number of shares displayed atbetter prices is greater than the first party's offer then there is noincentive for the second party to enter into the transaction. In otherwords, the first party provides liquidity to the second party providingthat liquidity is most efficiently priced.

Example B: party A places a limit order to buy 200,000 shares of MSFT at$25.23 into a trading system with a central order book. The NBB(National Best Bid) of MSFT is $25.25. Party B clicks on party A's orderand agrees to sell 200,000 shares of MSFT at $25.23. The trading systemattempts to grab all limit orders priced at $25.24 and $25.25 in it andother trading systems. The trading system executes 35,000 shares at anaverage trade price of $25.247. These trades are allocated to the PartyA. Party A now has a 165,000-share long position in MSFT at an averageexecution price of $25.226. Party B has sold his 200,000 share positionat $25.23. If party B had sent a market order, his execution price wouldhave been much lower than $25.23. Both parties benefit: party A gets abetter execution than he would otherwise receive, and Party B benefitsbecause he was able to dispose of his entire position at a greater pricethan he would have obtained had he sent in a market order.

FIG. 34 depicts another embodiment in which the activation of a limitorder in the central order book is conditioned based on price deviationsoff prices from trailing time periods for pegged orders. Example: “Don'tactivate my limit order if the bid price has moved more that 1% from thebid price five minutes ago.” Users may enter trailing time period inseconds and a maximum percentage price deviation away from thedesignated peg quote of the NBBO.

This embodiment allows a user to enter the number of minutes behindcurrent time (Time Tail) that the peg price of the equity will betracked and the maximum acceptable price deviation in percentage termsfrom the current price to the past tracked price point (steps 3400 and3410). Past price point may be calculated (steps 3420 and 3430) based on15 second price readings. Activation conditions of orders may not beshown in the book.

Example: XYZ Stock is trading at $100.00 at 10:00 A.M. The LiquidityProvider gives the order a 5-minute prior price time condition with a ½percent maximum allowed deviation. The system will track all prices fiveminutes behind the current quote. In this case the order will only beactivated if at 9:55 A.M. the price was between $99.50 to $100.50. Thismay be implemented, for example, by the system dividing an absolutevalue of the difference between the current best bid price and the priorbest bid price by the current best bid _(p)rice, and determine whetherthe resulting deviation is less than or equal to the specified ½ percentmaximum allowed deviation. This provides protection to the largest oforders from unscrupulous traders attempting to hijack the peg quotebefore executing their trade. Each time the peg price changes the marketsimply does not know if a sitting limit order will remain available.

FIG. 35 illustrates the components of a basic computing device inaccordance with an embodiment of the present invention, which mayinclude trading client 1000, trading client 1010 and trading server1020. The computing device may be a personal computer, workstation,server, handheld personal digital assistant (“PDA”), smart phone, or anyother type of microprocessor-based device. The computing device mayinclude one or more of processor 3510, input device 3520, output device3530, storage 3540, and communication device 3560.

Input device 3520 may include a keyboard, mouse, pen-operated touchscreen or monitor, voice-recognition device, or any other device thatprovides input. Output device 3530 may include a monitor, printer, diskdrive, speakers, or any other device that provides output.

Storage 3540 may include volatile and nonvolatile data storage,including one or more electrical, magnetic or optical memories such as aRAM, cache, hard drive, CD-ROM drive, tape drive or removable storagedisk. Communication device 3560 may include a modem, network interfacecard, or any other device capable of transmitting and receiving signalsover a network. The components of the computing device may be connectedvia a physical bus or wirelessly.

Software 3550, which may be stored in storage 3540 and executed byprocessor 3510, may include, for example, the application programmingthat embodies the functionality of the present invention (e.g., asembodied in the Deep Peer-To-Peer Midpoint Crossing System by DeepLiquidity, Inc.). Software 3550 may include a combination of serverssuch as application servers and database servers.

Network 1005 may include any type of interconnected communicationsystem, which may implement any communications protocol, which may besecured by any security protocol. The corresponding network links mayinclude telephone lines, DSL, cable networks, T1 or T3 lines, wirelessnetwork connections, or any other arrangement that implements thetransmission and reception of network signals.

The computing device may implement any operating system, such as Windowsor UNIX. Software 3550 may be written in any programming language, suchas C, C++, Java or Visual Basic. In various embodiments, applicationsoftware embodying the functionality of the present invention may bedeployed on a standalone machine, in a client/server arrangement orthrough a Web browser as a Web-based application or Web service, forexample.

Several embodiments of the invention are specifically illustrated and/ordescribed herein. However, it will be appreciated that modifications andvariations of the invention are covered by the above teachings andwithin the purview of the appended claims without departing from thespirit and intended scope of the invention. For example, the datastructures that implement the present invention can take many differentforms yet still provide the same functionality. Similarly, any processesconducted at a trading client application could be processed at the maintrading server and vice versa; keeping these processes at the clientapplications simply protects users from information leakage to theoperator of the main trading server. Additionally, all embodiments ofthe invention can be used for several types of financial instrumentsincluding, for example, stocks, ETFs, funds, bonds, contracts, options,futures, commodities and currencies.

1. A computer-implemented method for facilitating trading of financialinstruments, comprising: receiving an indication of interest to trade afinancial instrument by a first party; providing the indication ofinterest to other parties without disclosing a side of trade; receivingan offer to trade the financial instrument by a second party based onthe provided indication of interest, a side of trade being associatedwith the offer by the second party but not disclosed to the first party;and receiving either a rejection or an acceptance of the second party'soffer by the first party.
 2. The method of claim 1, wherein a side oftrade is associated with the acceptance by the first party.
 3. Themethod of claim 2, further comprising: completing a trade based on thesecond party's offer only if the side of trade associated with thesecond party's offer is contra to the side of trade associated with thefirst party's acceptance.
 4. The method of claim 2, further comprising:sending notification of the first party's acceptance to a tradingapplication without disclosing the side of trade associated with theacceptance.
 5. The method of claim 4, further comprising: sending theside of trade associated with the acceptance to the trading applicationonly upon occurrence of a specified market event condition.
 6. Themethod of claim 5, wherein the trading application completes a tradebased on the second party's offer only if the side of trade associatedwith the second party's offer is contra to the side of trade associatedwith the first party's acceptance.
 7. The method of claim 6, wherein thetrading application resides on a client machine of the second party. 8.The method of claim 7, wherein the trading application completes thetrade by submitting details of the trade to a trading server forexecution.
 9. The method of claim 6, wherein the trading applicationresides on a trading server.
 10. A computer-implemented method forfacilitating trading of financial instruments, comprising: displaying ina first portion of a graphical user interface an indication of interestto trade a financial instrument by a first party; displaying in a secondportion of the graphical user interface an offer to trade the financialinstrument by a second party based on the first party's indication ofinterest, a side of trade being associated with the offer by the secondparty but not disclosed to the first party; receiving either a rejectionor an acceptance of the second party's offer by the first party; andcompleting a trade based on the second party's offer only if the side oftrade associated with the second party's offer is contra to the side oftrade associated with the first party's acceptance.